Layering in user authentication

ABSTRACT

An asset is disclosed having a processing device and hardware with which to capture a biometric. The asset, with optional input from a remote server, may authenticate an identity of a medical staff member (MSM) with biometric recognition (and/or with other second factor authentication) upon the MSM attempting to access a medical database via the asset. The asset may receive a first location of the MSM from a real-time location system (RTLS) and retrieve a second location of a patient from the RTLS. The asset may further correlate the first location and the second location as being co-located, and thus grant the MSM access to identified data records of the patient within the medical database according to a security access level authorized the MSM. The correlation may include a location of the asset, which correlates to the location of the MSM before access is granted.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 62/146,084, filed Apr. 10, 2015, the entire contents of which are incorporated by reference.

BACKGROUND

As a company grows, a number of assets a company manages may increase. For example, with growth the company may increase its inventory, personnel, tools, vehicles, buildings, real estate, equipment, and so forth. Additionally, as a number of personal devices such as computers, cellphones, tablets, and so forth used by employees, contractors, and customers continue to increase, management of assets used and/or owned by a company may become increasingly difficult to track. A company may use asset-tracking systems (ATS) or, in a medical setting, a medical management system (MMS), to keep track of their assets. Where those assets include computing devices that provide access to confidential and/or sensitive data (such as available within a medical management system), authenticated access to the assets becomes a desired feature, in addition to tracking locations of the assets.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure in which like components may be labeled with corresponding numbering; and, wherein:

FIG. 1 illustrates a communication flow of asset and management information in a medical management system (MMS) according to various embodiments.

FIG. 2 is a diagram of an authentication system to authenticate access to the MMS according to one embodiment.

FIG. 3 is a flowchart of an exemplary method for validating credentials through the authentication system according to one embodiment.

FIG. 4 is a flowchart of an exemplary method for creating of a biometric for use in the authentication system according to one embodiment.

FIG. 5 is a flowchart of an exemplary method for updating a biometric being used in the authentication system according to one embodiment.

FIG. 6 is a flowchart of an exemplary method for deleting a biometric being used in the authentication system according to one embodiment.

FIG. 7 is a flowchart of an exemplary method for validating a biometric captured for use in the authentication system according to one embodiment.

FIG. 8 is a flowchart of an exemplary method for validating a biometric captured for use in the authentication system, according to another embodiment.

FIG. 9 is a flowchart of an exemplary method for validating a biometric and for handling a stored biometric that has become stale, according to one embodiment.

FIG. 10 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to one embodiment.

FIG. 11 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to another embodiment.

FIG. 12 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to yet another embodiment.

FIG. 13 illustrates a block diagram of one implementation of a computer system.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.

DETAILED DESCRIPTION

Assets of all kinds may be tracked and may be secured by providing selective access to authorized individuals through authentication of those individuals. The authentication may include second factor authentication, which may be required before an individual gains access to confidential or sensitive information available through a database accessible through the asset. The individuals may be an employee of any organization, military personnel in a military enterprise setting, government workers at any level in government, and medical personnel in a medical facility setting, or the like. When the term “asset” is referred to herein, it may be with relation to an asset accessible by any of these types of employees or personnel that may have access to confidential or sensitive information through different kinds of assets, such as mobile devices, computers, work stations and the like. For clarity and simplified explanation, the present disclosure is primarily described with reference to medical assets in a medical setting.

A medical asset may include equipment such as a medical cart, ventilators, an IV pole, a tablet computer, a battery pack, all in one (AIO) personal computer, and so forth. A military asset may include a mobile or stationary computer, a radio system, a workstation and a weapons system and the like. A government asset may include a mobile or stationary computer, a workstation, an authentication pad and the like. Because some assets involve computing devices (such as a medical cart, a tablet or personal computer), these assets may provide access to confidential or sensitive patient information records in a medical setting, a military setting, a government setting and in a business setting. Securing access to the assets becomes a challenge when the assets may be distributed throughout a medical facility such as a hospital, nursing home or medical clinic (or a military or government facility) and are generally difficult to keep under constant observation at all times.

Accordingly, the asset may function in conjunction with a server or remote computing device to authenticate access of a medical staff member (MSM) (or other user) to an asset and to a medical server or database that stores patient or medical information. The MSM may be a physician, a physician's assistant, a nurse, a medical technician, or a specimen collector, for example. In one embodiment, the medical asset may validate the identification of the MSM for access to the medical database through one or more authentication methods.

In another embodiment, other users may be military or government personnel such as, for example, officers of certain rank, soldiers, sailors, airmen or marines of certain rank, and government employees of certain general schedule (GS) rank. Additionally, or alternatively, personnel may be categorized by position. For example, in the military, personnel may be assigned to positions such as S1, personnel staff, commander, captain, executive officer (XO), S2, S3, S4, S6 and other command or staff members. In the government, personnel may similarly be assigned to a position, which could be a position of leadership, management, committee head or chair, and the like. These personnel may be authenticated through a computing system integrated within an asset or as a stand-alone workstation or the like for access to personnel records, or mission or planning documents, and/or to other confidential, sensitive records or information that may carry varying levels of security levels for authorized access. Accordingly, the “MSM” referred to herein may also be understood to refer to military or government personnel or other business or organization personnel as would be apparent to one of ordinary skill in the art having the benefit of this disclosure.

The asset may layer together several authentication methods to strengthen the accuracy and security of the authentication to access the hardware of the asset and/or a database application or program. This layering may be to require second factor authentication to include, but not be limited to, any combination of: a biometric, username, password, personal identification code (PIN) number, use of a rotation security code such as an RSA token, a swipe card or key fob, a secret shape, a gesture, and location information correlation of a medical staff member (MSM) or other user, a patient or other third party, and/or the asset. The biometric may include facial recognition, fingerprint recognition, iris recognition, palm print recognition, and so forth.

In one embodiment, an asset includes a processing device and hardware with which to capture a biometric. The asset, with optional input from a remote server, may authenticate an identity of a MSM with biometric recognition upon the MSM attempting to access the medical database via the asset. The asset may also receive a first location of the MSM from a real-time location system (RTLS) and retrieve a second location of a patient from the RTLS. The asset may further correlate the first location and the second location as being co-located, e.g., within a threshold distance of each other or in a same room or designated location. Based on a combination of the biometric authentication and the location correlation of the MSM and the patient, the asset may grant access, by the MSM, to identified data records of the patient within the medical database according to a security access level authorized to the MSM. Alternatively, or additionally, the correlation may further include a location of the asset that correlates to the location of the MSM before access is granted, which may allow the MSM to access a patient's information even when not co-located with the patient.

In another embodiment, the asset, with optional input from a remote server, may validate credentials received from a user through an input source to provide access to an authentication system used to authenticate access to a medical database server. Once past the credentials authentication, the asset may perform second factor authentication to increase security. In one example, the asset may capture a biometric of the user through a biometric capturing device as directed by the processing device. The asset may send the biometric captured of the user to an authentication server over a network in which is stored one or more biometrics for the user. The asset may then receive a validation from the authentication server authenticating the user based on the biometric meeting a threshold match with a stored biometric, and grant a level of access to records of the medical database server according to a security access level associated with the user.

FIG. 1 illustrates a communication flow of asset and management information in a medical management system (MMS) 100 according to various embodiments, in addition to aspects of a real-time location system (RTLS) that works with the MMS 100 for authentication as will be explained with reference to FIG. 2.

The communication flow may originate in a location such as a room 110, and may include beacon devices 102 and data sent from an asset 104 (e.g., a medical cart is shown). The asset 104 may be coupled with an asset tag device 105A or may include an asset tag manager 105B that runs on the asset 104 to determine a location of the asset 104. The data (including the location) may flow through a communication hub 106 (or other network device) and arrive at a server 108 (such as a medical database and/or an authentication server). In some embodiments, the data also, or alternatively, flows through a communications network 115, where the communications network 115 may include the communication hub 106. The data flow may also flow in the reverse direction from the server 108 and/or the communication hub 106 to the asset 104, e.g., in response to a request for medical information or records on a patient. The data may include asset and/or management data, medical information, patient information, authentication data, and other personal and security-related information and the like.

The MMS 100 may include a plurality of assets 104 as shown in FIG. 2. The beacon devices 102 may be fixed locations and may provide a location identifier (ID) for assets 104 to detect, such that the assets 104 may determine a current location, which the assets may transmit through the communication hub 106 to the server 108. The beacon device 102 may identify or be associated with any type of location, including a room, a hallway, a common or conference room, and/or a grid location.

The beacon device 102 may include a circuit board within a housing, the circuit board containing a processor (or discrete logic or controller or microcontroller), memory (potentially non-volatile and/or volatile memory), a battery (or other power source), and a transceiver primarily for transmitting. The beacon device 102 may be programmed to transmit a beacon signal containing data to identify the beacon device to other devices, such as to the asset tag device 105A or to the asset tag manager 105B running on a host machine of the asset 104.

In one example, the beacon device 102 may communicate with the asset tag device 105A and/or the asset tag manager 105B through a personal area network (PAN), such as, e.g., with Bluetooth® technology developed by the Bluetooth Special Interest Group (SIG). In another example, the PAN may be created with Bluetooth® low energy (BLE) technology (also developed by Bluetooth SIG) that may be used to track the assets 104. For example, a BLE-based beacon may be associated with an asset in the MMS 100 to communicate asset and/or management information of the asset.

In another example, the beacon device 102 may be an active or passive radio frequency identification (RFID) tag that transmits a unique RFID number. The RFID number or identifier may be correlated at the server 108 with a certain location such as may have been pre-programmed at the server 108 or within a distributed MMS 100. In this example, the asset tag device 105A and/or the asset tag manager 105B may be or include an interrogator that interrogates the RFID tag of the beacon device 102 to determine the RFID number or identifier of the beacon device 102. When the beacon device 102 is an active RFID tag, the asset tag device 105A and/or the asset tag manger 105B may receive the actively transmitted RFID number of identifier as transmitted by the beacon device 102.

The asset tag device 105A (e.g., a non-integrated asset tag device) may be implemented in hardware and include a circuit board within a housing, the circuit board containing a processor, memory (potentially non-volatile and/or volatile memory), a battery, and a transceiver. The transceiver may be a third-party integrated circuit, such as an RF module, e.g., a Bluetooth® chip, an RFID interrogator and/or receiver or the like. The asset tag device may be performed by processing logic comprising hardware, software, firmware or any combination thereof.

The asset tag manager 105B (e.g., an integrated asset tag device) may be a software program (including instructions) that may utilize a processor, memory, transceiver and the like of a host machine of the asset 104, such as the medical cart (all-in-one (AOI)), any medical device in which the asset tag is integrated, or any device when used in non-medical applications.

The beacon device 102, and the located assets 104, may be tracked with a real-time location system (RTLS) that determines the location of whatever is tagged (or otherwise tracked by identifying a location of beacon devices 102 in proximity of the assets 104). The tracked entities may include an asset or equipment, a MSM and/or patient(s), for example. The communications hub 106 may be wired or wireless and may direct data between the assets and to (and from) the assets 104 and the server 108.

In one example, the beacon device may broadcast a location ID to any device located within the room 110. In this example, when the asset 104 receives the location ID from the beacon device 102, the asset 104 may determine its location. Alternatively, or additionally, the asset 104 may measure a received signal strength indication (RSSI) from the beacon device 102 to determine a location of the device within a radius or area for which the beacon device is designated.

For example, the asset 104 may use the received location ID from the beacon device 102 to determine that the asset 104 is located in an identified room. The asset 104 may also use the RSSI to determine a location of the asset 104 within the room, such as within a threshold of location accuracy (e.g., within X distance from the beacon device 102). In one example, a room may include multiple beacon devices 102. The asset 104 may receive multiple location IDs from the multiple beacon devices 102 and use the RSSI of the different location IDs to determine the location of the asset 104 within the room. For example, the asset 104 may use the RSSI of the different location IDs to triangulate the location of the asset 104 in the room. In another example, the beacon device 102 may be located at different locations. For example, the beacon device 102 may be located in a hallway, in a lobby, in a stairwell, in a room, in a parking lot, and so forth.

When the asset 104 determines its location, the asset 104 may communicate asset information (such as location information, asset management information, and so forth) to a closest communication hub 106. In one example, the communication hub 106 may be a device (such as a communication plate) mounted to a wall. In another example, the communication hub 106 may be integrated into a construction of a location. For example, the communication hub 106 may be integrated into a floor, ceiling, or wall of a facility, for example. In another example, the communication hub 106 may be software on the server 108.

In one example, the communication hub 106 may be located at a different location than the room 110 (such as a central location on the floor where the device is located or a central location in the building where the device is located). When the communication hub 106 receives the asset information from the asset 104, the communication hub 106 may relay the information to a server 108. In one example, the communication hub 106 may receive information from different devices. When the communication hub 106 receives the information from the different devices, the communication hub 106 may aggregate the data and send the aggregated asset information to the server 108.

One advantage of the asset 104 determining its location and sending the asset management information to the communication hub 106 may be to enable the beacon device 102 to be small and low energy. For example, because the beacon device 102 broadcasts the location ID, the beacon device 102 may consume a small amount of power (such as a 1-2 Ah per day) and may be powered by a small battery for an extended period of time. The asset 104 may have a separate power supply that may be recharged more easily than the beacon device 102. Another advantage of the asset 104 communicating the asset information may be that the asset 104 may select the information of the asset 104 to be communicated to the communication hub 106 and communicate the information in real-time and directly to the communication hub 106 to reduce communication interference from a plurality of devices.

In one example, the MMS 100 may track the assets 104 in real-time or substantially real-time. For example, the asset 104 may continuously communicate asset and management information to the communication hub 106.

In another example, the MMS 100 may track the assets on a periodic basis. For example, the asset 104 may communicate asset and management information to the communication hub 106 on a periodic basis. In another example, the communication hub 106 may transmit a request to the asset 104 to communicate the asset and management information. When the asset 104 receives the request, the asset 104 may communicate the asset and management information to the communication hub 106.

In one example, the MMS may include an implementation system to map a facility where assets may be managed, e.g., determine a schematic or layout of the facility. In another example, the implementation system may include software to determine a schematic or layout of the facility, including rooms, stairway objects, hallway objects, and so forth, based on a digital plan and/or a computer-assisted built plan within the software. In another example, a user may use a scanner, such as a three-dimensional (3D) scanner and walk around the facility collecting layout information, where the software may use the information from the scanner to determine the layout of the facility.

With further reference to FIG. 1, when the implementation software has determined a layout of the facility, the software may associate the beacon devices 102 and/or the communication hub 106 may be associated with the layout of the facility. For example, the beacon devices 102 and/or the communication hubs 106 in a facility may have a unique ID. When the facility layout is determined, the implementation software may receive input from an input device (such as a mouse, a keyboard, a stylus, a touch screen, and so forth) associating the different unique IDs with locations on the facility layout.

In another example, locations in the facility layout may have unique IDs associated with the location. In this example, an assistance device (such as a scanner or a communication device) may be taken to one or more locations in the facility, where the location ID may be selected, the assistance device may scan or communicate with the beacon device 102 and/or the communication hub 106, and the beacon device 102 and/or the communication hub 106 may be associated with the location ID. In another example, when a device is located at a facility location, the assistance device may scan the location for the beacon devices 102 and/or the communication hubs 106 (such as by using by using Bluetooth® scanning) and associate the beacon device 102 and/or the communication hub 106 scanner in the location with a location ID. For example, a user may walk into a room with a first location ID, use a tablet with Bluetooth® capabilities to scan the room for the beacon devices 102 and/or the communication hubs 106, and the software may associate the beacon devices 102 and/or the communication hubs 106 detected by the tablet with the first location ID. The user may repeat this process for multiple locations in the facility.

In yet another example, the beacon devices 102 may have a predefined number or identifier (ID). When a layout of the building is compiled, the user may use a graphical user interface (GUI) to select which beacon device is located in each room, hallway, conference room and the like.

An advantage of the implementation of the MMS 100 may be to enable integration of the MMS into a preexisting facility, e.g., the MMS may be installed in a preexisting facility and the implementation system may map the preexisting facility. Another advantage of the MMS may be that the installation and implementation of the MMS may enable quick and efficient installation as the MMS may be installed and configured for a facility without invasively installing an asset management system. Another advantage of the MMS may be that the system may avoid interference by other devices by using the implementation system to determine optimal locations of the beacon devices 102 and/or the communication hubs 106.

FIG. 2 is a diagram of an authentication system 200 to authenticate access to the MMS 100 of FIG. 1, including a medical database, according to one embodiment. In this example, the authentication system 200 may include a plurality of assets 104, a medical database server 250, a real-time location system (RTLS) 220 and an authentication server 230. The medical database server 250 may include a medical database 254 including patient records 255 and other personal and confidential information needing authenticated, or secured, access by medical staff members (MSMs).

The RTLS 220 may include a plurality of beacons and/or tags with which are associated location identifier (IDs) as discussed with reference to FIG. 1, which may be stored in the location IDs database 222. The RTLS 220 may further include a staff locations database 224 to store and track locations of the MSMs based on tags (or other locater) positioned in badges, bracelets and the like worn by the MSMs. The RTLS may further include a patient locations database 226 to store and track locations of patients within a medical facility, such as with tags (or other locator) positioned in badges, bracelets (or other device that is attached to the patient), or attached to a bed or other equipment of the patient, such as an IV tower.

Each of the assets 104 (such as a medical cart and the like previously listed) may include hardware and software that provides the ability to locate and/or confirm locations of individuals and other assets, and to authenticate MSMs and other users for access to a medical application and/or database. In FIG. 2, an exemplary asset is shown as Asset_n, which may include, but not be limited to a processing device 202, a scanner 211 (or interrogator as may be needed to locate passive RFID tags), biometric hardware 213, a biometric capturer 214, a global positioning system (GPS) device 218, and/or other location determining hardware and/or software.

The biometric capturer 214 may be integrated within or work in conjunction with the processing device 202 (or include instructions executed by the processing device) and the biometric hardware 213 to capture a biometric of a user. As will be discussed in more detail, the biometric may be validated against one or more stored biometrics, or may be captured as an initial biometric for a new user against which future authentication attempts are compared.

The processing device 202 may include, but not be limited to, a locator 212, a correlator 206, and an authenticator 216. The locator 212 may work with the scanner 211, the GPS device 218, and/or the RTLS 220 to determine the location of a patient, an MSM, its own location or that of another asset. The locator 212 may work according to RFID or BLE-based technology, based on GPS, Wi-Fi® developed by the Wi-Fi Alliance, or cellular technology, and/or based on received signal strength (RSSI), for example. The locations of MSMs, the patient and/or the asset may be used, whole or in part, for authenticating MSMs for access to the asset 104, and thus the medical database 254.

The correlator 206 may perform correlations between these locations, e.g., between the locations of the MSM requesting access to the asset and medical database, a patient for which the MSM requests information and/or the asset 104 located in a room or the proximity of the patient. For example, the correlator 216 may determine whether the MSM is co-located with the patient (e.g., within the same room) and/or whether the asset 104 itself is co-located in the same room with the patient. Given a location, the asset 104 (with optional input from the RTLS 220), may determine in what room of the medical facility that location resides. In this way, the asset 104 may correlate, at least at a room or area level, the locations of the MSM, a patient and the asset 104.

The authenticator 216 may run the general authentication process at the asset level as will be explained in more detail, which may include second factor authentication of the MSM (or user) wanting to access the asset, and the medical database 254 including the patient records 255. The authentication may also include results of the location correlation performed by the correlator 206, and thus improve the accuracy and security of the authentication of the user. In one embodiment, at least one form of authentication includes validation of a biometric captured by the biometric capturer 214 and biometric hardware 213 of the asset. The authenticator 216 may run any series of authentications, which may be driven by an algorithm or group of algorithms. After successful validation of an identity of the MSM, and passing the required authentication, the authenticator 216 may grant access by the MSM to the medical database server 250 (e.g., via an application or program).

In one embodiment, the authentication server 230 may include, but is not to be limited to, the processing device 202, an account manager 234, a staff accounts database 238, an access codes database 242, a biometrics database 244, and a security access level database 246. In one example, the authentication server 230 and the medical database server 208 may be located on different servers or may be two separate databases on a single server. In another example, the authentication server 230 and the medical database server 208 may be integrated as a single server, and so reference to one or the other may be more for the benefit to ease explanation than to require that certain processes be executed by one, or that certain data be stored by one, as compared to the other. For example, even if separate, the authentication server 230 may still act as a gatekeeper to access by MSMs to the medical database 254 located on the medical database server 208.

In one example, the processing device 202 of the authentication server 230 may be substantially the same as the processing device 202 of the asset 104. In other words, the authentication server 230 may perform substantially the same locating, correlating and/or authenticating functions across the network 115 on behalf of the asset 104, e.g., such that processes requiring more processing power and/or access to the above-listed databases may be performed all in the same location. In another example, one or more process may be performed by the processing device 202 at the asset 104 and one or more other process may be performed by the processing device of the authentication server 230. When authentication is completed, the authentication server 230 may send a positive validation indication to the asset 104, which may then grant access to the MSM that has been authenticated.

In one embodiment, the account manager 234 may create a security access account for each new medical staff member (MSM) (such as a doctor, nurse, aide and the like) wanting access to the medical database 254. The account manager 234 may then set up access codes for each MSM such as a username, password, PIN and swipe card ID, secret shape, gesture, badge tap and the like which may be stored in the access codes database 242. The account manager 234 may further coordinate the capture of a biometric of the new MSM by the asset (or other computer within the medical facility) to begin a baseline against which to compare future biometrics. If set up with facial or iris recognition or the like, the account manager may request to obtain more than one image, such as from different angles or in differing lighting conditions, on which to build a set of baseline images against which to compare future biometric validations. The authentication server 230 may store the captured and updated biometrics in the biometrics database 244.

The account manager 234 may further be directed to set a certain security access level for each MSM and store the security access levels in the security access level database 246 in relation to the corresponding staff account 238. Each security access level may dictate a certain level of access to patient records 255 and personal information permitted by corresponding MSMs (or officers, enlisted, government personnel of differing positions). For example, different individuals may have different security access levels, which may mean access to less or more information or access to information of a different quality, e.g., less or more confidential or sensitive.

In one example, a doctor may access complete patient information, including treatment information, medication charts, personal information, and so forth. In this example, a nurse's aide may have limited access to the patient information and be limited to accessing treatment information and medical carts. Furthermore, a specimen collector or medical technician may have still further limited information as may be dictated on a need to know basis according to their respective job descriptions.

In another example, a commander in the military, the Si and personnel staff may access entire records of military personnel within their unit, while other personnel within the unit may only access their own personal record(s). In a further example, a leader of a government agency may access all data records of personnel within their stewardship but those personnel may only be able to access their own data record(s). Similarly, personnel with certain positions or clearance levels may be provided access to differing levels of confidential or sensitive strategy and planning documents based on security level granted to those personnel.

Returning to a medical setting, patient information and/or security level information may be associated with facial recognition information. In this example, doctors may access soft assets, such as patient information, by providing a device in the MMS 100 with facial recognition information.

In one example, the identity of the individual may be tied to the location of the device. For example, when a doctor enters a room in a hospital with an asset 104 like a medical cart with an integrated computer system, the medical cart may determine the identity of the doctor using facial recognition and the location of the medical cart. In one example, the medical cart may authenticate the identity of the doctor. When the identity is confirmed, the medical cart may determine the location of the doctor. When the doctor is located in a patient's room that the doctor is treating, the medical cart may display a patient's information to the doctor. When the doctor is located in a patient's room that the doctor is not treating or in another location that is not the patient's room the medical cart may deny access to the patient information. In another example, when the doctor is not located in the patient's room, the medical cart may request additional security information prior to providing the doctor with access to the patient information.

In another example, when the asset 104 enters a location, such as the patient's room, the device may determine the location of the device, the identity of the individual, and determine the security access level of the individual. Based on the location information, identify information, and security access level, the asset 104 may access patient information and provide the user of the device with the patient information in view of their security access level.

In yet another example, the device can also use facial recognition to determine the identity of the patient. For example, when the doctor enters the patient's room, the device may determine what patient is assigned to that room and then use facial recognition to verify that an individual in that room is the assigned person.

In another example, the asset 104 may access facial recognition information for individuals using the MMS 100. In this example, the asset 104 may communicate with a communications hub 106 of the authentication system 200 requesting facial recognition information of the doctor. The communications hub 106 may access the authentication server 230 in which is stored the facial recognition information and communicate the facial recognition information back to the device. In another example, the asset 104 may directly access the authentication server 230 without need to access the communications hub 106. In either case, the asset 104 may access the security access level (via the communications hub or directly) as stored in the security access levels database 246.

When a user (or MSM) enters a room with an asset 104, the asset 104 may authenticate the ID of the user. In one example, the asset 104 may authenticate the ID of the user using a biometric sensor such as a facial recognition scanner, a fingerprint scanner, a voice recognition scanner, and so forth. In another example, the asset 104 may authenticate the ID of the user using a non-biometric authentication method such as a personal identification number (PIN) code, an RFID badge, a magnetic strip badge, a secret shape, a gesture and so forth.

When the asset 104 determines the location of the device and the ID of the user, the asset 104 may determine an access level of the user for that location. For example, the device may determine that the user is a doctor working at a hospital that is treating a patient located in the room where the device is located. The device may then determine that the doctor has full access to the patient's medical information and provide the user with access to this information. In another example, the user may be a nurse located in the patient's room. When the asset 104 determines that the user is a nurse located in the patient's room, the asset 104 can determine that the nurse has limited access to the patient's medical records and provide the limited information.

In another example, the asset 104 may determine the patient assigned to a location and automatically pull up the patient information when the device authenticates the user's ID and the location of the device. When the asset 104 leaves the location and/or the user of the device changes, the asset 104 may restrict access to the patient information until the location of the device and the ID of the user may be determined. In one example, a doctor may enter a patient room with the asset 104. The asset 104 may determine that the doctor is allowed access to the patient's information while located in the room and automatically display the patient information to the doctor while the doctor is in the room. When the doctor or the device leaves the room the access to the patient information ceases. In this example, the doctor may be making rounds to different patient's rooms and at the rooms the asset 104 may automatically provide the doctor access to the patient information while the doctor is located in the patient's room.

Facial identification may be used as a biometric interface to login to an asset 104. The asset login process may allow for integration with a single sign-on (SSO) security server. Components used for the facial identification may include a central biometric data store, an enrollment application and a biometric capture application. The biometric enrollment application may be executed by the account manager 234 and may have the ability to associate a staff account with biometric data. The biometric capture application may authenticate captured biometric data against the biometrics stored in the biometrics database 244 and can login using credentials stored in the access codes database 242. The biometric can be full face utilizing streaming image capture via an internal or external camera. Networking communication for facial recognition may be used for authentication to a common biometric server.

Authentication of a user with biometric data may occur when the asset 104 sends biometric-captured data to the authentication server 230. This authentication may have two results, valid or invalid. When the biometric is determined to be valid the staff account may be logged into the asset 104. When the biometric is determined to be invalid, the asset may not be logged in and continue the cycle for authentication.

In one example, images stored in the biometrics database 244 for facial recognition may be either native or mirrored. In one example, the mirrored image an image in a reversed orientation (e.g., a mirrored reflection). In another example, the native and mirrored images may be mixed between each other. In another example, the native and mirrored images may not be mixed between each other. Biometric identification may fail when a face was enrolled from a mirrored image, and later a non-mirrored face image is used for recognition (or vice versa). For example, some cameras or devices can be configured to produce mirrored images or may even produce them by default, and different cameras or configurations may be used during enrollment and identification. In one embodiment, the face images can have a uniform orientation, where all images are either native or mirrored, e.g., but not mixed between each other.

Authentication in video mode may be used together with a liveness detector, which may be integrated within the authenticator 216, and which checks that the image for which a biometric is captured is a live person (not a photo, for example). This prevents granting access to an asset with an image of the subject. Detection of “liveness” may include, but not be limited to, detecting blinking of eyes, moving the head around, tilting the head, moving the head closer to or further from the camera, and/or slightly changing facial expression. Liveliness may also be detected using other sensors such as a microphone where the user speaks a given phrase or using voiceprint identification.

When the authentication server 230 has a positive result from the supplied biometric, the asset 104 may be logged in with the associated user database account. When the authentication server 230 has a negative result from the supplied biometric, the asset 104 may not be logged in and can continue the cycle for biometric authentication. When a biometric is authenticated against the biometrics database 244, and the MSM's account is disabled, the asset may not be logged in.

In one example, the authentication system 200 may include a layered authentication of a user. For example, the authentication system 200 may perform a first layer or primary security authorization, such as a facial recognition authentication. Based on the first layer security authorization, the security system may perform one or more additional activities, such as, for example: (1) a second layer authentication and/or a third layer authentication, such as discussed previously; (2) provide access to the medical database server 250 to which the asset 104 is connected; (3) request additional information; (4) reject a request to access the medical database server 250; and/or (5) to perform other predetermined actions.

When layering in authentication as discussed above, greater or fewer layers of authentication may be used depending on the level of accuracy (or strength) with which the user is identified at each subsequent layer and/or a level of confidentiality of the information attempting to be accessed. When some doubt exists or authentication is performed with a weaker method, a next layer may increase the difficulty of spoofing or hacking the authentication. For example, a first layer may be a username and password, a second layer may be a PIN number, a third layer may be a random security code (like an RSA token), a fourth layer may be a biometric, and a fifth layer may include further second factor authentication, where these layers may have their orders changed in various embodiments. By way of further example, when the first layer provides 50% accuracy, then the MSM may add a second layer of authentication. When the second layer increases the accuracy to 75%, the MSM may add additional layers until accuracy reaches a predetermined level, such as 85% or 90% or the like.

In one example, the authentication system may enable a user to access a device or a database using a single sign-on (SSO), such as with use of facial recognition authentication. FIG. 3 is a flowchart 300 of an exemplary method for validating credentials through the authentication system 200 according to one embodiment.

In the present example, an asset 104 may perform a set of two authentications either in parallel or serially. A user may input credentials (such as username/pas sword, PIN, access card, or the like) into a keyboard or other input device (302). The authenticator 216 may then determine whether the credentials are captured (304) and validate the credentials at the authentication server 130, with a check with stored access codes in the access codes database 242.

The asset 104 may further prompt the user to provide a biometric for authentication (312), or some other form of identification. The authenticator 216 may then determine whether the biometric is captured (314) and then validate the biometric at the authentication server 130, with a check with stored biometrics in the biometrics database 244.

The authenticator 216 may then determine whether a valid response is received from the authentication server for the credential validation and the biometric validation (318). The asset 104 may then retrieve an operating system credential and send the operating system credential to a third party single sign-on (SSO) server 330. An operating system credential (e.g., an SSO credential) may include a username and password, a PIN or other authentication identifier obtained by the operation system. In some embodiments, a positive validation by the authentication server 130 may act as SSO credential for access to all applications and software of the asset.

The asset 104 may further get user environment settings from a cloud server 350 or the like (324). The asset 104 may then set an environment for user access to certain applications or features available through the asset based on the validation of the biometric, the SSO credentials, and/or the operation system credential. Part of the access granted may include access to software or an application through which the medical database 254 is accessed and queried.

In one example, the authentication system 200 may automatically log a user out after a period of inactivity or when the user may not be adjacent the asset 104 for a threshold period of time. When the user may be logged out, the authentication system may retain a previous state of the system for a threshold period of time. For example, when a user may be logged out, the authentication system 200 may maintain the last known system configuration for 10 minutes. When the same user logs back into the system within 10 minutes, the authentication system 200 may bring back up the last known system configuration. When the user logs back in after the 10 minutes have expired, the system 200 may be reset to a default configuration.

In another example, the authentication system 200 may anticipate when a user may use a device. For example, the authentication system 200 may use a camera to monitor when the user (e.g., through facial recognition) is approaching the device and may automatically log the user in and configure the device based on user preferences.

FIG. 4 is a flowchart 400 of an exemplary method for creating of a biometric for use in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (410). The asset 104 may then select an account appropriate for the user (420), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (430) and continue to attempt capture until successful (430). Upon successful capture, the asset may create the biometric and send the captured biometric for storage in the biometrics database 144, e.g., in conjunction with user's staff account (440).

FIG. 5 is a flowchart 500 of an exemplary method for updating a biometric being used in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (510). The asset 104 may then select an account appropriate for the user (520), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (530) and continue to attempt capture until successful (530). Upon successful capture, the asset may update the biometric (e.g., a previously captured or stored biometric) and send the updated biometric for storage in the biometrics database 144, e.g., in conjunction with user's staff account (540). Updating a biometric recognizes that a biometric may change over time, such as facial features may change with fluctuating weight or age in the example of facial recognition.

The updating the biometric process may also involve authenticating an identity of the user associated with the stored (or stale) biometric before updating or replacing the stored biometric with an updated biometric. The authentication as disclosed elsewhere herein may include a primary authentication, and alternatively, a primary authentication and a second factor authentication such as layered authentication approaches to increase the accuracy and the security of making updates to the biometrics. (See FIG. 9 for more details and an alternative embodiment.)

FIG. 6 is a flowchart 600 of an exemplary method for deleting a biometric being used in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (610). The asset 104 may then select an account appropriate for the user (620), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether to delete a biometric and continue to operate until successful deletion (630). The asset 104 may then direct the authentication server to delete the biometric from the biometrics database 144 (640). Deletion of a biometric may occur such as based on an account of a user being removed, deleted or changed, or in the case a staff account needs to be recreated from scratch, including creation of access codes and biometrics. The biometric may also be removed when an active database changes, which may include a different list of authorized users.

FIG. 7 is a flowchart 700 of an exemplary method for validating a biometric captured for use in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (710). The asset 104 may then select an account appropriate for the user (720), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (730) and continue to attempt capture until successful (730). The asset 104 may then request the authentication server 230 to validate the captured biometric with one or more biometrics stored in the biometrics database 144 (740). The asset 104 may then determine whether the biometric is valid (750), e.g., based on receipt of a valid or invalid response from the authentication server 230. When valid, the asset 104 may alert or inform the user of successful validation (760), and thus grant access to the user. When invalid, the asset 104 may alert or inform the user of the failure (770), and optionally prompt the user for a different biometric or other form of authentication.

FIG. 8 is a flowchart 800 of an exemplary method for validating a biometric captured for use in the authentication system 200, according to another embodiment. After a user (e.g., a medical staff member) logs in with a keyboard (or the like) (810), the asset 104 may determine whether biometric validation is available (820). If not, the asset 104 may prompt the user for other authentication (830) and validate the other form of authentication (840), which may be another biometric, a username/password, PIN, access card or the like. If yes, the asset 104 may attempt to capture a biometric of the user until successful (850). The asset 104 may then request the authentication server 230 to validate the biometric as done in the method of FIG. 7 (860). When the authentication server returns a response that the biometric is valid, the asset may alert or inform the user that the biometric is valid (870). When the authentication server returns a response that the biometric is invalid, the asset 104 may prompt the use to create another biometric (or try again to capture the same biometric again) that may be used for comparison for later authentications of the user (880).

FIG. 9 is a flowchart 900 of an exemplary method for validating a biometric and for handling a stored biometric that has become stale, according to one embodiment. The asset 104 may determine whether a biometric has been captured (910), until successfully capturing the biometric (910). The asset 104 may then direct the authenticator 216 (at the asset or at the authentication server 230) to validate the biometric based on comparison with one or more biometrics stored in the biometrics database 244 in relation to the user's staff account (920).

The asset may then determine whether the biometric is valid (930) based on a response from validating the biometric in step 920. When the asset determines that the biometric is not valid, the asset may restart the authentication process with attempting again to capture the biometric (or a different type of biometric) (910). When the asset determines that the biometric is valid, the asset may determine whether the biometric is more than a certain number of days old (for example older than a week, a fort night, etc.) (940). When the biometric is older than the certain number of days, the asset 104 may alert the user to update (or replace) the biometric (950) as performed in FIG. 5. The asset 104 may then also receive a login credential of the user (960) for a layered authentication before granting the user access to the medical database.

With further reference to step (940) in FIG. 9, a weighting may be applied to a biometric which may change (e.g., decrease) as the biometric ages. The weighting may also be adjusted based on verified lighting conditions or other factors that may affect the reliability of a captured biometric.

In one example, the facial recognition system may malfunction or be unable to authenticate the user. For example, the facial recognition system may not be able to communicate with the authentication server 230 to access facial recognition information. In one example, when an asset 104 is at a location where the network 115 is not available, then a login or badge tap may be used for authentication. In one example, when the login or badge tap may be used for authentication, the user may be granted limited access to the asset 104 or information available through the asset. For example, the user may not be able to login to patient records but could generally access the authentication system 200 for diagnostics, troubleshooting and the like. In another example, the user may be restricted to only accessing power assistance systems to move the cart to a location where the network 115 is available. In another example, an asset 104 may backup facial recognition information on the asset 104 and may use the backup facial recognition information to authenticate a user. One advantage of the asset 104 using the facial recognition system may be to provide a standalone authentication system. Another advantage of the asset 104 using the facial recognition system may be to save time by eliminating a manual login for authentication.

In one example, facial recognition may be used in combination with location information to authenticate an identity of a user. For example, an asset 104 may determine an identity of the user using the facial recognition system and then determine, based on the location of the asset 104, when the user is authorized to access the asset 104 or information on the device. For example, the facial recognition may authenticate the user but the asset 104 may be in a restricted area and deny access to the device and/or information on the asset 104.

FIG. 10 is a flowchart 1000 of an exemplary method for authenticating a medical staff member for access to the MMS according to one embodiment. An asset may detect that a medical staff member (MSM) has entered a patient room (1004) and update a location of the MSM based on method disclosed above (1008). The MSM may attempt to access the asset (e.g., an all-in-one PC, a tablet, a medical cart or the like) (1012). To authenticate the MSM's access, the asset may capture a biometric (1016) and receive second factor authentication (1020). The asset (and/or the authentication server) may then determine whether the biometric and the second factor authentication are valid (1024). If the authentication is not valid, the asset denies access by the MSM (1028). If the authentication is valid, the asset grants access by the MSM to the asset (1032).

The asset may continue to detect the MSM attempting to access patient health record software (1036). In response to the detection, a single sign-on (SSO) server may retrieve the MSM's credential for the health record software on behalf of the asset (1040). The asset may determine whether the MSM's credentials are valid (1044). If not valid, the asset may deny access to the health record software (1028). If valid, the asset may grant access by the MSM to the health record software with a proper security access level corresponding to the MSM's security access rights. The asset may then request patient data from a medical database (e.g., as stored in a medical database) (1052). The asset may, in one embodiment, then determine whether the patient corresponding to the requested patient data is located at the MSM's location (1056). If the MSM is not co-located with the patient, no records are returned, e.g., access may be denied (1060). If the MSM is co-located with the patient, the MSM may provide access to the patient health data according to the MSM's security access level.

FIG. 11 is a flowchart 1100 of an exemplary method for authenticating a medical staff member for access to the MMS 100 of FIG. 1 according to another embodiment. An asset may authenticate the identification (ID) of a medical staff member (MSM) with biometric recognition (1110). The asset may then receive a first location of the MSM from a real-time location system (RTLS) or from data provided by the RTLS (1120). The asset may also receive a second location of a patient from the RTLS (1130). The asset may then correlate the first location with the second location to generate a first correlation, in determining whether the MSM is co-located with the patient (1140). The asset may also correlate the second location with a location of the asset to generate a second correlation (1150). The asset may then determine whether a positive correlation has been provided for the first correlation, and alternatively, for both the first and second correlations (1160). If not, the method may loop back to block 1120. If yes, the asset may grant access to medical records of the patient in accordance with the security access level of the authenticated MSM (1170).

FIG. 12 is a flowchart 1200 of an exemplary method for authenticating a medical staff member for access to the MMS 100 of FIG. 1 according to yet another embodiment. An asset may validate credentials received from a user (such as a medical staff member) through the asset (1210). The asset may capture a biometric of the user through a biometric capturing device (1220). The asset may then send the captured biometric to an authentication server (1230). The asset may then receive a validation of the captured biometric from the authentication server (1240). The asset may then grant a level of access to records of the medical database server according to a security access level associated with the user (1250). The method of FIG. 12 may be combined with the method of FIG. 11 in alternative embodiments.

FIG. 13 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 1300 within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” may also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed in the present disclosure.

The exemplary computer system 1300 includes a processing device (processor) 1302, a main memory 1304 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 1306 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1318, which communicate with each other via a bus 1330.

Processing device 1302 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 1302 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 1302 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 1302 is configured to execute instructions 1326 for performing the operations and steps discussed herein.

The computer system 1300 may further include a network interface device 1334. The computer system 1300 also may include a video display unit 1308 (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), or a touch screen), an alphanumeric input device 1310 (e.g., a keyboard), a cursor control device 1314 (e.g., a mouse), and a signal generation device 1316 (e.g., a speaker).

The data storage device 1318 may include a machine-readable storage medium 1324 on which is stored one or more sets of instructions 1326 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 1326 may also reside, completely or at least partially, within the main memory 1304 and/or within the processing device 1302 during execution thereof by the computer system 1300, the main memory 1304 and the processing device 1302 also constituting computer-readable storage media. The instructions 1326 may further be transmitted or received over a network 115 via the network interface device 1334.

While the machine-readable storage medium 1324 is shown in an exemplary implementation to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” may also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “computer-readable storage medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

In the foregoing description, numerous details are set forth. It may be apparent, however, to one of ordinary skill in the art having the benefit of this disclosure, that the present disclosure may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present disclosure.

Some portions of the detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those that may use physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “segmenting”, “analyzing”, “determining”, “enabling”, “identifying,” “modifying” or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

The words “example” or “exemplary” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example’ or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X includes A or B” is intended to mean any of the natural inclusive permutations. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Moreover, use of the term “an embodiment” or “one embodiment” or “an implementation” or “one implementation” throughout is not intended to mean the same embodiment or implementation unless described as such.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.”

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations may be apparent to those of skill in the art upon reading and understanding the above description. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. 

What is claimed is:
 1. A system comprising: a processing device to run a medical cart; computer-readable memory storing data and instructions for access to a medical database server, wherein the instructions are executable by the processing device to perform biometric recognition on medical staff members; wherein the processing device is to execute the instructions to: authenticate an identity of a medical staff member with biometric recognition; receive a location of the medical staff member from a real-time location system (RTLS); correlate the location of the medical staff member with a location of a patient; and grant access to data records of the patient on the medical database server according to a security access level authorized the medical staff member, as authenticated, in response to co-location of the medical staff member and the patient.
 2. The system of claim 1, wherein the processing device is further to execute the instructions to receive a location of the medical cart, and wherein to correlate the location further includes to correlate the location of the medical cart with the location of the patient.
 3. The system of claim 1, wherein the biometric recognition comprises facial recognition, further comprising: a camera to capture a first image of the medical staff member; a database storing second images against which to match the first image using facial recognition software; and wherein the processing device is further to deny access to the data records of the patient when the first image does not sufficiently match any of the second images.
 4. The system of claim 3, further comprising a networked device accessible over a network in which is stored the database and on which is executed the facial recognition software.
 5. The system of claim 1, wherein the security access level authorized the medical staff member depends on a role of the medical staff member, and wherein a first role is granted access to more confidential data records than a second role.
 6. The system of claim 1, wherein the location of the medical staff member or the patient is received as an indicator from a tracking device, wherein the indicator is at least one of a personal area network (PAN) indicator, a received signal strength indicator (RSSID), or a radio frequency identification (RFID) indicator.
 7. The system of claim 1, wherein the processing device is further to execute the instructions to, in response to a failure to correlate the location of the medical staff member with the location of the patient, deny access to records of the patient by the medical staff member.
 8. The system of claim 1, wherein the processing device is further to execute the instructions to require second factor authentication of the identity of the medical staff member comprising at least one of: a swipe card; a personal identification number or password; a biometric other than facial recognition; or a decryption key of a public-key cryptosystem.
 9. A method comprising: authenticating, by a processing device incorporated within an asset, an identity of a medical staff member with biometric recognition upon the medical staff member attempting to access a medical database via the asset; receiving a first location of the medical staff member from a real-time location system; retrieving a second location of a patient from the real-time location system; correlating, using the processing device, the first location and the second location as being co-located; and granting the medical staff member memory access, by the processing device, to identified data records of the patient within the medical database according to a security access level authorized the medical staff member.
 10. The method of claim 9, wherein the medical database is stored at a medical database server with which the asset communicates over a network, the method further comprising retrieving the security access level of the medical staff member from the medical database server before granting access.
 11. The method of claim 9, wherein the security access level of a physician is higher than the security access level of a nurse, and wherein the security access level of a nurse is higher than the security access level of a specimen collector.
 12. The method of claim 9, further comprising denying the medical staff member access to the medical database in response to failure to authenticate the identity of the medical staff member or failure to correlate the first location and the second location as being co-located.
 13. The method of claim 9, wherein, to authenticate the identity of the medical staff member, the method further comprising requiring second factor authentication of the identity of the medical staff member comprising any or a combination of: a swipe card; a gesture; a secret shape; a personal identification number; a second biometric; and a decryption key of a public-key cryptosystem.
 14. The method of claim 9, further comprising determining the first location from a location tracking device located on the medical staff member.
 15. The method of claim 9, further comprising determining the second location from a location tracking device on the patient, on a bed of the patient, or based on a location of the asset.
 16. The method of claim 9, wherein the correlation comprises a first correlation, the method further comprising: determining a third location of the asset; correlating the first location with the third location to generate a second correlation; and wherein granting access by the medical staff member to the identified data records of the patient is dependent on the first correlation and the second correlation.
 17. A processing device to execute instructions stored in non-transitory computer readable storage medium to: validate credentials received from a user through an asset to provide access to an authentication system used to authenticate access to a medical database comprising medical information; authenticate an identity of the user through a first type of user authentication; determine a level of accuracy of the first type of user authentication; perform additional authentication of the identity of the user through at least a second type of user authentication until an accuracy level of a combination of the first type and the at least the second type of user authentication exceeds a predetermined threshold level of accuracy; and grant a level of access to records of the medical database according to a security access level associated with the user responsive to reaching the predetermined threshold level of accuracy of user authentication.
 18. The processing device of claim 17, wherein the first type or the at least the second type of user authentication comprises biometric recognition, and further to execute the instructions to: capture a biometric of the user through a biometric capturing device; send, over a network, the biometric captured of the user to an authentication server in which is stored one or more biometrics for the user; and receive a validation from the authentication server authenticating the user based on the biometric meeting a threshold match with a stored biometric.
 19. The processing device of claim 18, wherein, upon receipt of the validation from the authentication server, further to execute the instructions to provide the user single sign-on access to applications that access the medical database according to the security access level of the user.
 20. The processing device of claim 17, wherein the user is a medical staff member, and further to execute the instructions to: receive a first location of the medical staff member from a real-time location system; receive a second location of a patient from the real-time location system; determine a third location of the asset; correlate the first location with the second location and with the third location; and deny the user access to the records of the medical database when the first location fails to sufficiently correlate with the second location or with the third location.
 21. The processing device of claim 20, further to execute the instructions to determine the location of the patient from a location tracking device on the patient or based on a location of the asset. 